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The validation of requirements is a fundamental step in the development process of safety-critical 
systems. In safety critical applications such as aerospace, avionics and railways, the use of formal 
methods is of paramount importance both for requirements and for design validation. Nevertheless, 
while for the verification of the design, many formal techniques have been conceived and applied, 
the research on formal methods for requirements validation is not yet mature. The main obstacles 
are that, on the one hand, the correctness of requirements is not formally defined; on the other hand 
that the formalization and the validation of the requirements usually demands a strong involvement 
of domain experts. 

We report on a methodology and a series of techniques that we developed for the formalization 
and validation of high-level requirements for safety-critical applications. The main ingredients are 
a very expressive formal language and automatic satisfiability procedures. The language combines 
first-order, temporal, and hybrid logic. The satisfiability procedures are based on model checking and 
satisfiability modulo theory. We applied this technology within an industrial project to the validation 
of railways requirements. 

1 Introduction 

Formal methods are widely used in the development process of safety-critical systems. The application 
of formal verification techniques relies on the formalization of the system's design into a mathematical 
language. Several formal languages are available according to the different aspects that are relevant to the 
verification, and many design tools can automatically formalize the design into one of these languages. 
The verification techniques typically trade-off the automation of the analysis with the expressiveness of 
the specification language. State-of-the-art approaches mix model checking and theorem proving in order 
to tackle the verification of infinite-state systems with a sufficient level of automation. 

Another important aspect of the development process is the correctness of the requirements. Very 
often bugs in the late phases are caused by some flaws in requirements specification. These are difficult 
to detect and have a huge impact on the cost of fixing the bug. Nevertheless, formal methods on require- 
ments validation are not yet mature. In particular there is no precise definition of correct requirements. 

The most relevant solution has been proposed in the context of the property-based approach to de- 
sign, where the development process starts from listing a set of formal properties, rather than defining 
an abstract-level model. The requirements validation is performed with a series of checks that improve 
the confidence in the correctness of the requirements. These checks consist of verifying that the require- 
ments do not contain contradictions and that they are neither too strict to forbid desired behaviors, nor 
too weak to allow undesired behaviors. This process relies on the availability of a sufficiently expres- 
sive logic so that properties as well as desired and undesired behaviors can be formalized into formulas. 
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The approach considers a one-to-one mapping between the properties and the logical formulas. This 
allows for traceability of the formalization and the validation results, and for incremental and modular 
approaches to the validation. 

In the context of safety-critical applications, the choice of the language used to formalize the re- 
quirements is still an open issue, requiring a delicate balance between expressiveness, decidability, and 
complexity of inference. The difficulty in finding a suitable trade-off lies in the fact that the requirements 
for many real-world applications involve several dimensions. On the one side, the objects having an ac- 
tive role in the target application may have complex structure and mutual relationships, whose modeling 
may require the use of rich data types. On the other side, static constraints over their attributes must be 
complemented with constraints on their temporal evolution. 

One of the main obstacle in applying this approach to the industrial level is that requirements are 
often written in a natural language so that a domain knowledge is necessary both to formalize them 
and to define which behaviors are desirable and which not during the validation process. Since domain 
experts are typically not advanced users of formal methods, they must be provided with a rich but friendly 
language for the formal specification and an automatic but scalable engine for the formal verification. 

In this paper, we report on a methodology and a series of techniques that we developed for the for- 
malization and validation of high-level requirements for safety-critical applications. The methodology 
is based on a three-phases approach that goes from the informal analysis of the requirements, to their 
formalization and validation I CRSTOSaJ . The methodology relies on two main ingredients: a very ex- 
pressive formal language and automatic satisfiability procedures. The language combines first-order, 
temporal, and hybrid logic IICRSTOSbl [CRST091 ICRTOQI . The satisfiabiUty procedures are based on 
model checking and satisfiability modulo theory. We applied this technology within an industrial project 
to the validation of railways requirements. The tool liCCM"'"09 l integrates, within a commercial environ- 
ment, techniques for requirements management and model-based design, and advanced techniques for 
formal validation with the model checker NuSMV MCCGROOII . 

The rest of the paper is organized as follow: in Section |2l we outline the proposed methodology, 
giving details on the chosen language in Section 12.11 and on the validation procedure in Section I2.2[ 
in Section [3l we describe the project where the methodology was appUed; in Section |4l we review the 
related work, and in Section [51 we conclude. 

2 A methodology for the formalization and validation of requirements 

Our methodology has been presented in HCRSTOSall . It consists of three main steps: 

• Informal analysis. The first activity in the methodology is the informal analysis of the set of 
requirements. In this phase, first the requirement fragments are identified and categorized on the 
basis of their characteristics. Then, they are structured according to their dependencies. 

• Formalization. The second phase consists of the formalization of each categorized requirement 
fragment identified in the informal analysis by specifying the corresponding formal counterpart. 
The link between informal and formal is used for requirements traceability of the formalization 
against the informal textual requirements, and to select directly from the textual requirements 
document a categorized requirement fragment to validate. 

• Formal validation. The third phase aims at improving the quality of the requirements and increas- 
ing the confidence that the categorized requirement fragment and its corresponding formalized 
counterpart meet the design intent. It consists of the definition of a series of validation problems 
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and the analysis of the resuhs given by an automatic vaUdation check. The problems include three 
main types of checks; namely, checking logical consistency, scenario compatibihty, and property 
entailment: 

- Logical consistency to formally verify the absence of logical contradictions in the considered 
formaUzed requirement fragments. It is indeed possible that two formahzed requirement 
fragments mandate mutually incompatible behaviors. Note that this check does not require 

any domain knowledge. 

- Scenario compatibility to verify whether a scenario is admitted given the constraints imposed 
by the considered formalized requirement fragments. Intuitively, the check for scenario com- 
patibility can be seen as a form of simulation guided by a set of constraints. The check for 
scenario compatibility can be reduced to the problem of checking the consistency of the set 
of considered formalized requirement fragments with the constraint describing the scenario. 

- Property entailment to verify whether an expected property is implied by the considered for- 
malized requirement fragments. This check is similar in spirit to model checking, where 
a property is checked against a model. Here the considered set of formalized requirement 
fragment plays the role of the model against which the property must be verified. Prop- 
erty checking can be reduced to the problem of checking the consistency of the considered 
formahzed requirement fragments with the negation of the property. 

If one of the check reveals a problem, two causes are possible: the first one is that the formal- 
ization is not correct due to an improper use of the formal language or to an ambiguity of the 
informal specification; the second possibility is that there is a flaw in the informal specification 
that needs to be corrected. An inspection of the diagnostic information can be carried out in order 
to discriminate among the two possibilities in order to take the most appropriate corrective action. 

In fact, the above checks not only produce a yes/no answer, but they can also provide the domain 
expert with diagnostic information, mainly in the form of: 

- Traces. When consistency and scenario checking succeeds, it is possible to produce a trace 
witnessing the consistency, i.e. satisfying all the constraints in the considered formalized 
requirement fragments. Similarly, when a property check fails the tool provides a trace wit- 
nessing the violation of the property by the formalized requirement fragments. 

- Unsatisfiable core. If the specification is inconsistent or the scenario is incompatible, no 
behavior can be associated to the considered formalized requirement fragments; in these 
cases, the tool can also generate diagnostic information in the form of a minimal inconsistent 
subset. This information can be given to the domain expert, to support the identification and 
the fix of the flaw. 



2.1 A property specification language for safety-critical applications 

The success of the methodology relies on the availability of a specification language which is enough 
expressive to represent the requirements of safety-critical applications, and enough simple to be used by 
domain experts and analyzed with automatic techniques. 

In order to specify requirements in the context of safety-critical applications we adopt a fragment 
of first-order temporal logic. The first-order component allows to specify constraints on objects, their 
relationships, and their attributes, which typically have rich data types. The temporal component allows 
to specify constraints on the temporal evolution of the possible configurations. We enriched the logic with 
constructs able to specify hybrid aspects of the objects' attributes such as derivatives of the continuous 
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variables and instantaneous changes of the discrete variables. The logical formulas are consequently 
interpreted over hybrid traces where continuous evolutions alternate with discrete changes. Finally, the 
logic has been designed in order to be suitable for an automatic analysis with model checking techniques. 

As described in IICRST09II . we use a class diagram to define the classes of objects specified by the 
requirements, their relationships and their attributes. The class diagram basically defines the signature of 
the first-order temporal logic. The functional symbols that represent the attributes and the relationships 
of the objects are flexible in the sense that their interpretation change at different time points. Quantifiers 
are allowed to range over the objects of a class, and can be intermixed with the temporal operators. 

The basic atoms of the logic are arithmetic predicates of the attributes and relationships of objects. 
As described in IICRT09L the "next" operator can be used to refer to the value of a variable after a discrete 
change, while the "der" operator can be used to refer to the first derivative of continuous variables during 
a continuous evolution. 

The temporal structure of the logic encompasses the classical linear-time temporal operators com- 
bined with regular expressions. This combination is well established in the context of digital circuits and 
forms the core of standard languages such as the Property Specification Language (PSL) IIEF06I . 

On the lines of PSL, we also provide a number of syntactic sugar which increases the usability of the 
language by the domain experts. This includes natural language expressions that substitute the temporal 
operators, the quantifiers, and most of the mathematical symbols. 

2.2 Model checking techniques for requirements validation 

The validation process of the proposed methodology relies on a series of satisfiability checks: consis- 
tency checking is performed by solving the satisfiability problem of the conjunction of the formalized 
requirements; the check that the requirements are not too strict is performed by checking whether the 
conjunction of the requirements and the scenario's formulas is satisfiable; finally, the check that the re- 
quirements are not too weak is performed by checking whether the conjunction of the requirements and 
the negation of the property is unsatisfiable. 

Unfortunately, the satisfiability problem of the chosen language is undecidable. The undecidability 
comes independently from the combination of temporal and first-order logics, from the combination of 
the uninterpreted functions and quantifiers, and from the hybrid component of the logic. 

Nevertheless, we want to keep such expressiveness in order to faithfully represent the informal re- 
quirements in the formal language. Thus, we rely on automatic albeit incomplete satisfiability proce- 
dures. 

First, we fix a number of objects per class so that it is possible to reduce the formula to equi-satisfiable 
one free of quantifiers and functional symbols IICRST09II . As described in HCRSTOSbll . we can automat- 
ically find a bound on the number of objects for classes under certain restrictions. 

Second, we translate the resulting quantifier-free hybrid formula into an equi-satisfiable formula in 
the classical temporal logic over discrete traces. In this case, we exploit the linearity of the constraints 
over the derivatives to guarantee the existence of a piecewise-linear solution and to encode the continuity 
of the continuous variables into quantifier-free constraints. 

Third, we compile the resulting formula into a Fair Transition System (FTS) IIMP92II . whose ac- 
cepted language is not empty iff the formula is satisfiable. For the compilation we rely on the works 
described in [CRT08, CRST08b|. We apply infinite-state model checking techniques to verify the lan- 
guage emptiness of the resulting fair transition system. In particular, we used Bounded Model Checking 
(BMC) IIBCCZ99II . particularly effective in solving the satisfiable cases and producing short models. 
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and Counterexample-Guided Abstraction Refinement (CEGAR) lICGJ^OOt . more oriented to prove tlie 
unsatisfiability cases. 

Tiie language non-emptiness check for the FTS is performed by looking for a lasso-shape trace of 
length up to a given bound. We encode this trace into an SMT formula using a standard BMC encoding 
and we submit it to a suitable SMT solver. This procedure is incomplete from two point of views: first, 
we are performing BMC limiting the number of different transitions in the trace; second, unlike the 
Boolean case, we cannot guarantee that if there is no lasso-shape trace, there does not exist an infinite 
trace satisfying the model (since a real variable may be forced to increase forever). Nevertheless, we find 
the procedure extremely efficient in the framework of requirements validation. 

In order to prove the emptiness of the FTS, we use predicate abstraction. We adopt a CEGAR loop, 
where the abstraction generation and refinement are completely automated. The loop consists of four 
phases: 1) abstraction, where the abstract system is built according to a given set of predicates; the 
abstract state space is computing by passing to the SMT solver an ALLSAT problem; 2) verification, 
where the non-emptiness of the language of the abstract system is checked; if the language is empty, 
it can be concluded that also the concrete system has an empty language; otherwise, an infinite trace 
is produced; the abstract system is finite so that we can used classical model checking techniques; 3) 
simulation: if the verification produces a trace, the simulation checks whether it is realistic by simulating 
it on the concrete system; if the trace can be simulated in the concrete system, it is reported as a real 
witness of the satisfiability of the formula; the trace is simulated by checking the satisfiability of the 
SMT problem; 4) refinement: if the simulation cannot find a concrete trace corresponding to the abstract 
one, the refinement discovers new predicates that, once added to the abstraction, are sufficient to rule out 
the unrealistic path; also this step is solved with an SMT solver. 

3 The ETCS project 

The European Train Control System (ETCS) is a project supported by the European Union aiming at the 
implementation of a common train control system in all European countries to allow the uninterrupted 
movement of train across the borders. ETCS is based on the implementation on board of a set of safety 
critical functions of speed and distance supervision and of information to the driver. Such functions rely 
on data transmitted by track-side installations through two communication channels: fixed spot transmis- 
sion devices, called balises, and continuous, bidirectional data transmission through radio according to 
the GSM standard. ETCS is already installed in important railway Unes in different European countries 
(like Spain, Italy, The Netherlands, Switzerland) and installations are in progress in other countries, such 
as Sweden, UK, France, Belgium and also non-European railways such as China, India, Turkey, Arabia, 
South Korea, Algeria and Mexico. 

Since 2005, the European Railway Agency (ERA) is responsible of managing the evolution of the 
ETCS specifications (change control management), ensuring their consistency, and guaranteeing the 
backwards compatibility of new versions with the old ones. 

In 2007, ERA issued a call to tender for the development of a methodology complemented by a set of 
support tools, for the formalization and validation of the ETCS specifications. The activity poses many 
hard problems. First, the ETCS documents are written in natural language, and may thus contain a high 
degree of ambiguity. Second, the ETCS specifications are still in progress, and receive contribution by 
many people with different culture and background. Third, the ETCS comprises a huge set documents, 
and comes with severe issues of scalability. 

The EuRailCheck project, originated from the successful response to the call to tender by the con- 



A. Cimatti, M. Roveri, A. Susi, S. Tonetta 



73 



sortium composed by "Registro Italiano Navale (RINA)", a railway certifying body, "Fondazione Bruno 
Kessler - irst", a research center, and "Dr. Graband and Partners", a railway consultancy company. 

Within the project, we developed a support tool, covering the various phases of the described method- 
ology, based on the integration of algorithmic formal verification techniques within traditional design 
tools. Moreover, a realistic subset of the specification was formalized and validated applying the de- 
veloped methodology and tools. The results of the project were then further exploited and validated 
by domain experts external to the consortium. The evaluation was carried out in form of a workshop, 
followed by hands-on training courses. These events were attended by experts from manufacturing and 
railways companies, who provided positive feedback on the applicability in the large of the methodology. 

3.1 Tool support 

The EuRailCheck supporting tool, which has been designed and developed within the project, considered 
several user and technical requirements such as easy of use, and openness. 

The technological basis was identified in two tools provided by IBM: the RequisitePro suite was 
used as a front end for the management of the ETCS informal requirements; and, the Rational Soft- 
ware Architect (RSA) was used for the management of the formalization of the ETCS requirements 
into UML class diagrams and temporal constraints. RSA was chosen for its openness in the manipula- 
tion of UML specification, and its customizability thanks to the embedded Eclipse platform it is built 
upon. RSA worked as a gluing platform, and all the modules were developed as plug-ins for RSA. 
The main functionalities include RequisitePro custom tagging, annotation of UML diagrams with con- 
straints (syntax checking, completion), support for the instantiation to finite domains, control of the 
validation procedure. Moreover, we also developed, relying on the API provided by RequisitePro and on 
the Eclipse platform, the traceability links among the informal requirements classified in RequisitePro 
and their formal counterpart inside RSA. The verification back-end is based on an extended version of 
the NuSMV/CEGAR HCCGROOI model checker, able to deal with continuous variables, and to analyze 
temporally complex expressions in RELTL IIEF061 ICRST09l ICRT09I . 



4 Related work 

Several works faced with the problem of the formal specification and validation of requirements. Some 
of them focused on the problem of formalizing natural language specifications, other focused on the 
formal specification languages to be used in such a task, other proposed a methodological approach to 
the requirements representation and validation. 

On the first side, works such as ||FGR"'"94t and IIAG06II aim at extracting automatically from a natu- 
ral language description a formal model to be analyzed. However, their target formal languages cannot 
express temporal constraints over object models. Moreover, they miss a methodology for an adequate 
formal analysis of the requirements. Other works such as I GMM901 IBDZ97 1 provided expressive formal 
languages to represent the requirements. Although, the proposed languages have some similarities with 
ours such as the adoption of first-order temporal logic, they do not allow specification of hybrid aspects 
which are necessary for safety-critical applications. Also these works miss a methodology for the analy- 
sis of the formal requirements and the verification algorithms are perform either with interactive theorem 
proving or with model checking restricted to propositional sub-cases. 

Several formal specification languages such as Z |Spi92[, B IIAbr96ll . and OCL IIOMG06II have been 



proposed for formal model-based specification. They are very expressive but require a deep background 
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in order to write a correct formalization. Alloy fJacOT] is a formal language for describing structural 
properties of a system relying on the subset of Z [ Spi92| that allows for object modeling. An Alloy 
specification consists of basic structures representing classes together with constraints and operations 
describing how the structures change dynamically. Alloy only allows to specify attributes belonging to 
finite domains (no Reals or Integers). Thus, it would have been impossible to model the Train position as 
requested by the ETCS specifications. Although Alloy supports the "next" operator ("prime" operator) 
to specify the temporal evolution of a given object, it does not allow to express properties using LTL and 
regular expressions. 

Among the methodological approaches, in IIHJL961 . a framework is proposed for the automated 
checking of requirement specifications expressed in Software Cost Reduction tabular notation, which 
aims at detecting specification problems such as type errors, missing cases, circular definitions and non- 
determinism. Although this work has many related points to our approach, the proposed language is not 
adapt to formalize requirements that contain functional descriptions of the system at high level of ab- 
straction with temporal assumptions on the environment. Formal Tropos (FT) IISPGM05[ lFLM+041 and 
KAOS IIDDMvL97l lvL09 l are goal-oriented software development methodologies that provide a visual 
modeling language that can be used to define an informal specification, allowing to model intentional and 
social concepts, such as those of actor, goal, and social relationships between actors, and annotate the 
diagrams with temporal constraints to characterize the valid behaviors of the model. Both FT and KAOS 
are limited to propositional LTL temporal constraints, and thus not suitable for formalizing safety-critical 
requirements. 

5 Conclusions 

In this paper we described a recent research line that we are pursuing in the context of requirement 
validation for safety-critical applications. We developed an end-to-end methodology for the analysis 
of requirements, which combines informal and formal techniques. The property-based approach guar- 
antees traceability, by allowing for a direct correspondence between the components of the informal 
specification and their formalized counterparts. The formal specification language mixes linear-temporal 
logic with first-order and hybrid components. Automatic albeit incomplete techniques based on model 
checking are used to check consistency, entailment of required properties, and possibility of desirable 
scenarios. 

The methodology has been applied in a project with industrial partners for the formalization and 
validation of railways requirements. During the project, we developed a tool that integrates, within a 
commercial environment for traditional requirements management and model-based design, advanced 
techniques for formal validation. The tool has been used and validated by potential end users external to 
the project's consortium. 

In the future, we will pursue the following lines of activity. First, we will investigate the application 
of automated techniques for Natural Language Processing (e.g. automated tag extraction, discourse 
representation theory), in order to increase the automation of the first phase of the methodology. Second, 
we will explore extensions to the expressiveness of the formalism, the relative scalability issues of the 
verification tools. 

References 

[Abr96] J.-R. Abrial. The B-book: assigning programs to meanings. Cambridge University Press, 1996. 



A. Cimatti, M. Roveri, A. Susi, S. Tonetta 



75 



[AG06] V. Ambriola and V. Gervasi. On the Systematic Analysis of Natural Language Requirements with 

CIRCE. Autom. Softw. Eng., 13(1): 107-167, 2006. 
[BCCZ99] A. Biere, A. Cimatti, E. M. Clarke, and Y. Zhu. Symbolic Model Checking without BDDs. In 

TACAS, pages 193-207, 1999. 
[BDZ97] Philippe Du Bois, Eric Dubois, and Jean-Marc Zeippen. On the Use of a Formal R. E. Language - 

The Generalized Railroad Crossing Problem. In RE, pages 128-, 1997. 
[CCGROO] A. Cimatti, E. M. Clarke, F. Giunchiglia, and M. Roveri. NuSMV: A new symbolic model checker. 

577T, 2(4):410-425, 2000. 

[CCM+09] Roberto Cavada, Alessandro Cimatti, Alessandro Mariotti, Cristian Mattarei, Andrea Micheli, Sergio 
Mover, Marco Pensallorto, Marco Roveri, Angelo Susi, and Stefano Tonetta. Eurailcheck: Tool 
support for requirements validation. In Proceedings of the 24th IEEE/ACM International Conference 

Automated Software Engineering (ASE 2009), 2009. to appear 

[CGJ+00] E. M. Clarke, O. Grumberg, S. Jha, Y. Lu, and H. Veith. Counterexample-Guided Abstraction 
Refinement. In CAV, pages 154-169, 2000. 

[CRSTOSa] A. Cimatti, M. Roveri, A. Susi, and S. Tonetta. From Informal Requirements to Property-Driven 
Formal Validation. In FMICS, LNCS, L'Aquila, Italy, sep 2008. Springer. 

[CRSTOSb] A. Cimatti, M. Roveri, A. Susi, and S. Tonetta. Object models with temporal constraints. In SEFM, 
pages 249-258. IEEE Computer Society, 2008. 

[CRST09] A. Cimatti, M. Roveri, A. Susi, and S. Tonetta. Formalizing requirements with object mod- 
els and temporal constraints. Journal of Software and Systems Modeling (SoSyM), 2009. DOI 
10.1007/S10270-009-0130-7. 

[CRT08] A. Cimatti, M. Roveri, and S. Tonetta. PSL Symbohc Compilation. IEEE Trans, on CAD of Inte- 
grated Circuits and Systems, 27(10): 1737-1750, 2008. 

[CRT09] A. Cimatti, M. Roveri, and S. Tonetta. Requirements Validation for Hybrid Systems. In CAV 2009, 
LNCS, pages 188-203. Springer, 2009. 

[DDMvL97] R. Darimont, E. Delor, P. Massonet, and A. van Lamsweerde. GRAIL/KAOS: an environment for 
goal-driven requirements engineering. In ICSE'97, pages 612-613. ACM, 1997. 

[EF06] C. Eisner and D. Fisman. A Practical Introduction to PSL. Springer- Verlag, 2006. 

[FGR+94] A. Fantechi, S. Gnesi, G. Ristori, M. Carenini, M. Vanocchi, and P. Moreschini. Assisting Require- 
ment Formalization by Means of Natural Language Translation. Formal Methods in System Design, 
4(3):243-263, 1994. 

[FLM+04] A. Fuxman, L. Liu, J. Mylopoulos, M. Roveri, and P. Traverso. Specifying and analyzing early 
requirements in Tropos. Requirements Engineering, 9(2): 132-150, 2004. 

[GMM90] Carlo Ghezzi, Dino Mandrioli, and Angelo Morzenti. Trio: A logic language for executable specifi- 
cations of real-time systems. Journal of Systems and Software, 12(2): 107-123, 1990. 

[HJL96] C. L. Heitmeyer, R. D. Jeffords, and B. G. Labaw. Automated consistency checking of requirements 
specifications. Trans. Softw. Eng. Methodol, 5(3):231-261, 1996. 

[Jac02] D. Jackson. Alloy: a lightweight object modelling notation. ACM Trans. Softw. Eng. Methodol, 
ll(2):256-290, 2002. 

[MP92] Z. Manna and A. Pnueli. The Temporal Logic of Reactive and Concurrent Systems, Specification. 
Springer, 1992. 

[OMG06] OMG. Object Constraint Language: OMG available specification Version 2.0, 2006. 
[SPGM05] A. Susi, A. Perini, P. Giorgini, and J. Mylopoulos. The Tropos Metamodel and its Use. Informatica, 
29(4):401^08,2005. 

[Spi92] J. M. Spivey. The Z Notation: a reference manual, 2nd edition. Prentice Hall, 1992. 
[vL09] Axel van Lamsweerde. Requirements Engineering: From System Goals to UML Models to Software 
Specifications. Wiley, 2009. 



